Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bugfix] Fix broken bytecode dependency #14929

Merged
merged 13 commits into from
Oct 30, 2024
Merged

Conversation

fEst1ck
Copy link
Contributor

@fEst1ck fEst1ck commented Oct 10, 2024

Description

Fixed #14311. This PR continues the partial fix from @jasonxh #14340 by

  • extending OnDiskPackage
  • fix the way package metadata is extracted from the bytecode dependency in the original pr

The original issue is caused by CompiledPackage missing information for bytecode dependencies, which propagates to PackageMetadata when constructing transaction payloads.

How Has This Been Tested?

This is manually tested on the #14311

Type of Change

  • New feature
  • Bug fix
  • Breaking change
  • Performance improvement
  • Refactoring
  • Dependency update
  • Documentation update
  • Tests

Which Components or Systems Does This Change Impact?

  • Validator Node
  • Full Node (API, Indexer, etc.)
  • Move/Aptos Virtual Machine
  • Aptos Framework
  • Aptos CLI/SDK
  • Developer Infrastructure
  • Move Compiler
  • Other (specify)

Copy link

trunk-io bot commented Oct 10, 2024

⏱️ 1h 19m total CI duration on this PR
Slowest 15 Jobs Cumulative Duration Recent Runs
rust-move-unit-coverage 11m 🟩
rust-move-unit-coverage 11m 🟩
rust-move-tests 10m 🟥
rust-move-tests 10m 🟥
rust-move-tests 10m 🟩
rust-move-unit-coverage 10m 🟩
rust-cargo-deny 5m 🟩🟩🟩
check-dynamic-deps 4m 🟩🟩🟩🟩
general-lints 2m 🟩🟩🟩
semgrep/ci 2m 🟩🟩🟩🟩
dispatch_event 53s 🟥
dispatch_event 50s 🟥
dispatch_event 49s 🟥
file_change_determinator 49s 🟩🟩🟩🟩
dispatch_event 33s 🟥

settingsfeedbackdocs ⋅ learn more about trunk.io

@fEst1ck fEst1ck marked this pull request as draft October 10, 2024 06:35
Copy link

codecov bot commented Oct 10, 2024

Codecov Report

Attention: Patch coverage is 46.66667% with 64 lines in your changes missing coverage. Please review.

Project coverage is 60.1%. Comparing base (918b643) to head (9a8f9e1).

Files with missing lines Patch % Lines
...s/move-package/src/compilation/compiled_package.rs 46.0% 55 Missing ⚠️
aptos-move/framework/src/built_package.rs 50.0% 9 Missing ⚠️
Additional details and impacted files
@@           Coverage Diff           @@
##             main   #14929   +/-   ##
=======================================
  Coverage    60.1%    60.1%           
=======================================
  Files         856      856           
  Lines      210845   210905   +60     
=======================================
+ Hits       126742   126788   +46     
- Misses      84103    84117   +14     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@fEst1ck fEst1ck marked this pull request as ready for review October 10, 2024 08:58
@fEst1ck fEst1ck requested a review from vgao1996 October 10, 2024 16:55
Copy link
Contributor

@vgao1996 vgao1996 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, so I played with it and can confirm that it has fixed the create-object-and-publish-package workflow.

Left some comments on the implementation.

BTW I also discovered that aptos move unit-test would fail if you run it within a package with a bytecode dependency, so we should get that fixed as well. No need to include it in this PR though

Comment on lines +650 to +704
let (file_map, all_compiled_units, optional_global_env) =
match config.compiler_version.unwrap_or_default() {
CompilerVersion::V1 => {
let mut paths = src_deps;
paths.push(sources_package_paths.clone());
let compiler = Compiler::from_package_paths(
paths,
bytecode_deps.clone(),
flags,
&known_attributes,
);
compiler_driver_v1(compiler)?
},
version @ CompilerVersion::V2_0 | version @ CompilerVersion::V2_1 => {
let to_str_vec = |ps: &[Symbol]| {
ps.iter()
.map(move |s| s.as_str().to_owned())
.collect::<Vec<_>>()
};
let mut global_address_map = BTreeMap::new();
for pack in std::iter::once(&sources_package_paths)
.chain(src_deps.iter())
.chain(bytecode_deps.iter())
{
for (name, val) in &pack.named_address_map {
if let Some(old) =
global_address_map.insert(name.as_str().to_owned(), *val)
{
if old != *val {
let pack_name = pack
.name
.map(|s| s.as_str().to_owned())
.unwrap_or_else(|| "<unnamed>".to_owned());
bail!(
"found remapped address alias `{}` (`{} != {}`) in package `{}`\
, please use unique address aliases across dependencies",
name, old, val, pack_name
)
}
}
}
}
}
let mut options = move_compiler_v2::Options {
sources: sources_package_paths
.paths
.iter()
.map(|path| path.as_str().to_owned())
.collect(),
sources_deps: src_deps.iter().flat_map(|x| to_str_vec(&x.paths)).collect(),
dependencies: bytecode_deps
.iter()
.flat_map(|x| to_str_vec(&x.paths))
.collect(),
named_address_mapping: global_address_map
.into_iter()
.map(|(k, v)| format!("{}={}", k, v))
.collect(),
skip_attribute_checks,
known_attributes: known_attributes.clone(),
language_version: Some(effective_language_version),
compiler_version: Some(version),
compile_test_code: flags.keep_testing_functions(),
experiments: config.experiments.clone(),
..Default::default()
};
options = options.set_experiment(Experiment::ATTACH_COMPILED_MODULE, true);
compiler_driver_v2(options)?
},
};
let mut options = move_compiler_v2::Options {
sources: sources_package_paths
.paths
.iter()
.map(|path| path.as_str().to_owned())
.collect(),
sources_deps: src_deps.iter().flat_map(|x| to_str_vec(&x.paths)).collect(),
dependencies: bytecode_deps
.iter()
.flat_map(|x| to_str_vec(&x.paths))
.collect(),
named_address_mapping: global_address_map
.into_iter()
.map(|(k, v)| format!("{}={}", k, v))
.collect(),
skip_attribute_checks,
known_attributes: known_attributes.clone(),
language_version: Some(effective_language_version),
compiler_version: Some(version),
compile_test_code: flags.keep_testing_functions(),
experiments: config.experiments.clone(),
..Default::default()
};
options = options.set_experiment(Experiment::ATTACH_COMPILED_MODULE, true);
compiler_driver_v2(options)?
},
};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@fEst1ck it seems like these are just formatting changes. Can you confirm if this is indeed the case?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes.

Comment on lines 159 to 170
let mut bytecode_deps = vec![];
for dep_name in self.package.bytecode_deps.iter().copied() {
let bytecode_paths = self.get_compiled_units_paths(dep_name)?;
let mut addrs = BTreeSet::new();
for bytecode_path in bytecode_paths {
let addr = get_module_addr(dep_name, bytecode_path.as_str())?;
addrs.insert(addr);
}
for addr in addrs {
bytecode_deps.push((dep_name, addr));
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not so sure if the logic here is correct.

  1. get_compiled_units_paths doesn't seem to have the ability to locate a bytecode dependency just by its name (without the address)
  2. Similar to my other comment, there is no handling of duplicates

With that being said this function only seems to be referenced by some move-cli tests and it does not seem to be reachable from there either due to track_cov being set to false. Not sure if there's a good way to even test this.

fn run_all(args_path: &Path) -> datatest_stable::Result<()> {
    let cli_exe = env!("CARGO_BIN_EXE_move");
    let use_temp_dir = !args_path.parent().unwrap().join("NO_TEMPDIR").exists();
    run_one(
        args_path,
        &PathBuf::from(cli_exe),
        /* use_temp_dir */ use_temp_dir,
        /* track_cov */ false,
    )?;
    Ok(())
}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

removed this part and left a TODO

@@ -1138,3 +1173,23 @@ pub fn build_and_report_no_exit_v2_driver(
Some(env),
))
}

/// Returns the address of the module
fn get_module_addr(pkg_name: Symbol, pkg_path: &str) -> Result<NumericalAddress> {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if module_path would be a less confusing name

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fn get_package_module_addr or maybe fn get_addr_from_module_in_package might be a bit explicit with what this function does as well

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

Comment on lines 818 to 813
bytecode_deps: bytecode_deps
.iter()
.flat_map(|package| {
let name = package.name.unwrap();
package.paths.iter().map(move |pkg_path| {
get_module_addr(name, pkg_path.as_str()).map(|addr| (name, addr))
})
})
.try_collect()?,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I get that you're trying to get the address of a compiled package, but the implementation seems a bit awkward

  1. pkg_path technically already contains the address of the package (e.g. "/home/vgao/aptos-core/b/deps/0x8ae94b63db9b31761835258cd938ef670235069d37c17c616d06d28860dffe87/A/build/bytecode_modules/a.mv"), so you don't have to deserialize a module and then get the address from there.
  2. The current code does not seem to handle bytecode packages with multiple modules

Copy link
Contributor Author

@fEst1ck fEst1ck Oct 29, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. The package path part in the file structure 0x8ae94b63db9b31761835258cd938ef670235069d37c17c616d06d28860dffe87/A/build/bytecode_modules/a.mv is not required in the Move book.
  2. changed field to pub bytecode_deps: BTreeMap<PackageName, NumericalAddress>

Copy link
Contributor

@wrwg wrwg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would be nice to have a better explanation of what is actually fixed. Also, it might be hard, but there is no test case? In this case pl justify why not.

@@ -153,6 +156,18 @@ impl OnDiskCompiledPackage {
deps_compiled_units.push((dep_name, self.decode_unit(dep_name, &bytecode_path)?))
}
}
let mut bytecode_deps = vec![];
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a bit confused here -- isn't into_compiled_package only used by collect_coverage in the Move CLI? But the bug seems to be about deployment.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This part is irrelevant to this fix. Removed.

Since testing this requires publishing a package with bytecode dependencies which is hard to be done automatically, we tested this maually.

Copy link
Contributor

@vgao1996 vgao1996 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM for now. Can you add a comment at the location where you deleted the following code as well, just for more clarity?

        let mut bytecode_deps = vec![];
        for dep_name in self.package.bytecode_deps.iter().copied() {
            let bytecode_paths = self.get_compiled_units_paths(dep_name)?;
            let mut addrs = BTreeSet::new();
            for bytecode_path in bytecode_paths {
                let addr = get_module_addr(dep_name, bytecode_path.as_str())?;
                addrs.insert(addr);
            }
            for addr in addrs {
                bytecode_deps.push((dep_name, addr));
            }
        }

@rahxephon89 rahxephon89 self-requested a review October 29, 2024 20:21
@fEst1ck fEst1ck enabled auto-merge (squash) October 29, 2024 21:09

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

@fEst1ck fEst1ck enabled auto-merge (squash) October 30, 2024 00:06
@fEst1ck fEst1ck disabled auto-merge October 30, 2024 00:08

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

@fEst1ck fEst1ck enabled auto-merge (squash) October 30, 2024 00:50

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

Copy link
Contributor

✅ Forge suite realistic_env_max_load success on 5ab698896fa851aa7936ca80824ec98cabe4d1e6

two traffics test: inner traffic : committed: 14431.63 txn/s, latency: 2753.55 ms, (p50: 2700 ms, p70: 2700, p90: 3000 ms, p99: 3300 ms), latency samples: 5487560
two traffics test : committed: 100.10 txn/s, latency: 1377.87 ms, (p50: 1400 ms, p70: 1400, p90: 1500 ms, p99: 1700 ms), latency samples: 1820
Latency breakdown for phase 0: ["MempoolToBlockCreation: max: 1.974, avg: 1.561", "ConsensusProposalToOrdered: max: 0.321, avg: 0.293", "ConsensusOrderedToCommit: max: 0.367, avg: 0.356", "ConsensusProposalToCommit: max: 0.660, avg: 0.648"]
Max non-epoch-change gap was: 0 rounds at version 0 (avg 0.00) [limit 4], 0.95s no progress at version 2696201 (avg 0.20s) [limit 15].
Max epoch-change gap was: 0 rounds at version 0 (avg 0.00) [limit 4], 8.48s no progress at version 2696199 (avg 8.48s) [limit 15].
Test Ok

Copy link
Contributor

✅ Forge suite framework_upgrade success on 9c922ebe94f5ff4b58df4617f3ff003e2ce10ccd ==> 5ab698896fa851aa7936ca80824ec98cabe4d1e6

Compatibility test results for 9c922ebe94f5ff4b58df4617f3ff003e2ce10ccd ==> 5ab698896fa851aa7936ca80824ec98cabe4d1e6 (PR)
Upgrade the nodes to version: 5ab698896fa851aa7936ca80824ec98cabe4d1e6
framework_upgrade::framework-upgrade::full-framework-upgrade : committed: 1236.90 txn/s, submitted: 1238.56 txn/s, failed submission: 1.66 txn/s, expired: 1.66 txn/s, latency: 2680.41 ms, (p50: 2600 ms, p70: 3000, p90: 3900 ms, p99: 5300 ms), latency samples: 104120
framework_upgrade::framework-upgrade::full-framework-upgrade : committed: 1261.08 txn/s, submitted: 1264.39 txn/s, failed submission: 3.32 txn/s, expired: 3.32 txn/s, latency: 2335.21 ms, (p50: 2100 ms, p70: 2400, p90: 3600 ms, p99: 5100 ms), latency samples: 114100
5. check swarm health
Compatibility test for 9c922ebe94f5ff4b58df4617f3ff003e2ce10ccd ==> 5ab698896fa851aa7936ca80824ec98cabe4d1e6 passed
Upgrade the remaining nodes to version: 5ab698896fa851aa7936ca80824ec98cabe4d1e6
framework_upgrade::framework-upgrade::full-framework-upgrade : committed: 1286.84 txn/s, submitted: 1291.30 txn/s, failed submission: 4.46 txn/s, expired: 4.46 txn/s, latency: 2312.55 ms, (p50: 2100 ms, p70: 2400, p90: 3900 ms, p99: 5400 ms), latency samples: 115440
Test Ok

Copy link
Contributor

✅ Forge suite compat success on 9c922ebe94f5ff4b58df4617f3ff003e2ce10ccd ==> 5ab698896fa851aa7936ca80824ec98cabe4d1e6

Compatibility test results for 9c922ebe94f5ff4b58df4617f3ff003e2ce10ccd ==> 5ab698896fa851aa7936ca80824ec98cabe4d1e6 (PR)
1. Check liveness of validators at old version: 9c922ebe94f5ff4b58df4617f3ff003e2ce10ccd
compatibility::simple-validator-upgrade::liveness-check : committed: 16482.58 txn/s, latency: 2067.43 ms, (p50: 2100 ms, p70: 2100, p90: 2400 ms, p99: 3800 ms), latency samples: 528520
2. Upgrading first Validator to new version: 5ab698896fa851aa7936ca80824ec98cabe4d1e6
compatibility::simple-validator-upgrade::single-validator-upgrading : committed: 6697.52 txn/s, latency: 4201.59 ms, (p50: 4800 ms, p70: 5100, p90: 5200 ms, p99: 5300 ms), latency samples: 122240
compatibility::simple-validator-upgrade::single-validator-upgrade : committed: 6295.78 txn/s, latency: 5159.10 ms, (p50: 5200 ms, p70: 5300, p90: 7000 ms, p99: 7200 ms), latency samples: 224320
3. Upgrading rest of first batch to new version: 5ab698896fa851aa7936ca80824ec98cabe4d1e6
compatibility::simple-validator-upgrade::half-validator-upgrading : committed: 6124.80 txn/s, latency: 4462.41 ms, (p50: 5000 ms, p70: 5200, p90: 5300 ms, p99: 6000 ms), latency samples: 123480
compatibility::simple-validator-upgrade::half-validator-upgrade : committed: 6684.48 txn/s, latency: 4840.50 ms, (p50: 5100 ms, p70: 5300, p90: 6500 ms, p99: 7000 ms), latency samples: 231900
4. upgrading second batch to new version: 5ab698896fa851aa7936ca80824ec98cabe4d1e6
compatibility::simple-validator-upgrade::rest-validator-upgrading : committed: 8140.95 txn/s, latency: 3511.36 ms, (p50: 3300 ms, p70: 3700, p90: 5500 ms, p99: 5800 ms), latency samples: 147440
compatibility::simple-validator-upgrade::rest-validator-upgrade : committed: 7207.51 txn/s, latency: 4361.34 ms, (p50: 3600 ms, p70: 5300, p90: 5900 ms, p99: 8000 ms), latency samples: 272520
5. check swarm health
Compatibility test for 9c922ebe94f5ff4b58df4617f3ff003e2ce10ccd ==> 5ab698896fa851aa7936ca80824ec98cabe4d1e6 passed
Test Ok

@fEst1ck fEst1ck merged commit 1198729 into aptos-labs:main Oct 30, 2024
82 of 92 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Bug] Unable to publish package with bytecode deps
5 participants